The present invention relates to a microprocessor based electronic system and in particular to a virtual addressing scheme within a microprocessor based electronic system.
The use of virtual addressing in computer architecture is well known in the art. Virtual addressing allows a single program to operate independently of the actual resources of a system and independently of any other programs which may also be executing in the system.
With virtual addressing, a program uses addresses for instructions and data that do not necessarily correspond to the physical resources within a system that contains that information. The operating system and CPU then collaborate to translate these virtual addresses into the correct physical locations within a system, performing this translation dynamically.
Under this arrangement, the operating system determines the appropriate translation for a given task. By setting the translation on a per task basis, multiple tasks can use identical virtual addresses, but separate physical memory. Such a system allows tasks to be developed and initiated independently of each other, increasing system reliability and flexibility.
Similarly, using a xe2x80x9cvirtual memory system,xe2x80x9d the operating system can select which portions of which tasks are actually resident in system RAM, reducing the amount of actual memory the system must contain.
The process for managing the translation of virtual addresses to physical addresses is commonly called xe2x80x9cmemory management.xe2x80x9d Commonly, a structure referred to as a xe2x80x9ctranslation lookaside buffer,xe2x80x9d or xe2x80x9cTLB,xe2x80x9d is used as a cache of recent translations to allow the process to occur at full processor execution rates.
Although there are separate aspects to the various programs in a multi-tasking system, there are often portions of the task that are common to other tasks. For example, the subroutine xe2x80x9cprintfxe2x80x9d, which prints a string of characters to an I/O terminal, would typically be common to all tasks in a system. Similarly, there may be data areas common to multiple tasks in a system.
To support this operation, a typical memory management unit provides two modes of translation. In a first mode, a translation is available only to one particular task in the system. In the second mode, a given translation may be available to all tasks in the system, i.e., it is considered a xe2x80x9cglobal translation.xe2x80x9d
Sometimes in a multi-tasking system, however, it is desirable for some, but not all, tasks to share the same programs and/or data. For example, a router may have a master route table to which certain processes within the system should have access. For example, some processes require access to the route table to look up the proper route for a given packet and other processes are used to up-date the route table. However, it may be undesirable for other tasks in the system to inadvertently access the route table data structure as that may corrupt the contents of the data structure or violate a system security rule.
Conventionally, when a multi-tasking system shares translations among a specific subset of tasks, operating system xe2x80x9ctrapsxe2x80x9d are used. An operating system trap is a software subroutine, invoked by a system task, which provides a specific operating system service to the calling program. Thus, if a given system needs to share data among a specific set of tasks, the operating system can implement a subroutine that checks for access privilege and then performs the access as requested. In effect, the shared information is made directly accessible only to the operating system.
Unfortunately, the use of an operating system trap causes a significant loss of performance. When a trap occurs, the operating system must decode the reason for the trap, store the current state of the system for context preservation, perform the desired function, reinstate the current state of the system and resume operations. Consequently, the overhead for a single operating system trap can be in the order of micro-seconds, as a few dozen instructions are required.
A translation lookaside buffer (TLB), in accordance with an embodiment of the present invention, permits the sharing of data and/or programs among a subset of all tasks through the use of a group membership field. The TLB includes a plurality of entries, each of which includes at least a virtual page number and a group membership field that identifies a group of tasks that may utilize a respective translation, wherein the group of tasks is a subset of all tasks. The virtual address also has a group membership field that is compared with the group membership field in the TLB entry. The group membership field may include a number of bits, e.g., four bits. Each bit in the group membership field may indicate a different group. A translation is considered valid for a current task when corresponding bits in the group membership field in the virtual address and in the translation, i.e., in the TLB, are set. Thus, it is not necessarily required that the entire membership field match, but that a single bit within the field matches in the current task and the translation. In other embodiments, any number of bits within the group membership field may be required to match in both the current task and the translation. If there is a group membership match, the current task is permitted to utilize the translation. Each TLB entry may further include a global bit and an address space identifier. Thus, a given translation within the TLB may be valid for all tasks, only an individual task, or a group of tasks. If the translation may be used by the current task, a virtual page number, which is also included in the virtual address, is translated into a page frame number. The page frame number is then concatenated with an offset from the virtual address to form the physical address.
In accordance with another embodiment of the present invention, a method of translating a virtual address from a current task to a physical address includes issuing a virtual address from a current task to a TLB, the virtual address having at least a virtual page number. The virtual page number is compared to at least one TLB virtual page number to find a desired translation. It is then determined whether the current task is a member of a group of tasks that has access to the translation, the group including less than all tasks. This is accomplished, for example, by comparing the group membership field in the virtual address to the group membership field in the desired translation entry. If the current task does belong to a group that has access to the translation, the virtual page number is translated to a page frame number. The page frame number will then be concatenated with an offset in the virtual address to form the physical address.
With the use of a group membership field, a group of tasks, as opposed to all tasks or merely individual tasks, may be marked for access to a given translation. Accordingly, the task is not required to initiate an operating system trap to access shared data. Consequently, there is no performance degradation associated with operating system traps for accessing shared data. Further, the group membership field enables both limited sharing as well as system security and reliability.